Why Honcho over mem0
这是一页架构决策记录：2026-04-17 把团队记忆后端从 mem0 + Zilliz Cloud 切到 Honcho 托管的完整决策依据 + 6 条踩坑记录。
配套：Honcho（实体）、Honcho memory（范式）、Honcho 接入指南（怎么接）。
TL;DR
| 维度 | mem0 | Honcho |
|---|---|---|
| 范式 | 事实提取 + vector 召回 | 用户综合理解（dual-peer + Dreaming + Dialectic） |
| 后端 | 自托管 SDK + Zilliz Cloud | 托管（zero infra） |
| 自维护代码 | mem0_provider_new.py | 不需要（hermes 内置 honcho 插件） |
| 月成本 | Zilliz 月付 + 自维护时间 | $18-30 USD（5 hermes） |
| 团队当前实际状态 | 集成不稳，Zilliz collection 始终为空 | ✅ 业务路径全通 |
| 决策结果 | ❌ 退役 | ✅ 上线 |
Allen 拍板的真正驱动力：减运维。 不是技术先进性。
决策时序
| 时间 | 事件 |
|---|---|
| 2026-04-17 06:59 | 主 plan cleanup-and-3docs 完成，已经接入 mem0 + Zilliz |
| 2026-04-17 18:30 | Allen 提出 "Honcho" → 我建议 "3 个月后再考虑" |
| 2026-04-17 22:15 | Allen 强调 "我更在意运维负担" → 我修正建议为"立刻切" |
| 2026-04-17 23:13 | Honcho 注册 + 创建 workspace teamos-prod |
| 2026-04-18 00:55 | hermes-admin 第一次 status 显示 honcho active（但缺 key） |
| 2026-04-18 01:25 | dashboard 看到第一个真实 hermes session "data" |
| 2026-04-18 06:30 | 完整体检暴露问题：业务路径全 401（Global key 无写权限） |
| 2026-04-18 07:00 | 切 admin scope key + monkey patch delete_workspace |
| 2026-04-18 07:30 | hermes runtime 真业务路径 100% 通 ✓ |
主动工时：约 4 小时。
核心决策依据
1. Honcho 跟 mem0 不是替代关系，是不同层
| 维度 | mem0 | Honcho |
|---|---|---|
| 主用法 | "存事实，按 query 检索" | "存对话，问 chat 端点综合理解" |
| 输出 | fact 列表 | LLM-quality 推理 |
| 自动建用户画像 | ❌ | ✅ Dreaming Agent |
| 跨 session 召回 | vector 找 fact | chat 端点综合 |
- 输入 14 条消息（CI debug + 个人理财 app）
- 问 Honcho
"What should I know about this user?" - 答："this person developing personal finance app... notably thoughtful about UX (known vs surveilled tension)... business-minded calculating unit economics early"
mem0 给不了这种综合判断，只能给提取出的事实条。
2. 真正的"减运维"账
| 隐形运维成本 | mem0 | Honcho |
|---|---|---|
| 自维护 provider 代码 | mem0_provider_new.py（要测/升级/调） | ❌ 不需要 |
| Zilliz Cloud 配额管理 | 要看 | ❌ 无 |
| mem0 SDK 升级跟踪 | 要跟 | ❌ Honcho SDK 跟着 hermes 升级 |
| 出 bug 自己 debug | 社区小 | 有 Honcho 支持团队 |
| 嵌入模型/维度选择 | 要决策 | ❌ 自动 |
反直觉但真实：原以为 Honcho 是新组件 = 多运维。实际算账：Honcho 减运维，因为它把"自维护代码 + 自管 vector store + 自调试"全吃了。
3. 数据隔离粒度兼容
| 隔离需求 | mem0 实现 | Honcho 实现 |
|---|---|---|
| 团队内部 | namespace = workspace_id + collection | workspace_id（单 workspace） |
| 用户跨 hermes | user_id + agent_id | peer_id 命名（user-X-via-hermes-Y） |
| 跨成员防护 | 应用代码层 | 同 + Honcho _observation 配置 |
详见 ../system/隐私规则/HERMES_HONCHO_RETRIEVAL_GUARDRAILS。
4. mem0 的实际状态：从未稳定运行
体检发现的事实：
- Zilliz collection
_86lux_memo和mem0migrations都是空的（Zilliz API 返回 1802 = no records） /opt/data/.mem0/本地缓存只有 20KB（config.json + history.db）- admin / guohua / linjun 的 .env 里写的 mem0 配置都是孤儿（hermes runtime 实际从未真正调通）
- 切换 mem0 → Honcho 零数据迁移成本（没数据可迁）
踩坑记录（6 个）
切 Honcho 走通用了 4 小时，其中 80% 时间在踩这 6 个坑。未来人重复时直接看这里能省 3 小时。
坑 1：API key 复制带前缀字符
第一次 key 是 Ehch-v3-... 多了个 E 前缀（剪贴板/IME 吞字符）→ "Invalid API key"。
教训：贴 key 时确认前缀是 hch-v3-（无 E）。如果首次 401，先重新复制对照前缀。
坑 2：HONCHO_WORKSPACE_ID env 不被 SDK 读
设 .env 里 HONCHO_WORKSPACE_ID=teamos-prod 没用 → SDK 默认 fallback 到 "default"（docs 写的）或实际是 "hermes"（hermes plugin 默认 host name）。
教训：必须写到 /opt/data/honcho.json 显式指定 workspace 字段。env 只能传 API key。
坑 3：Honcho dashboard SCOPE 选 Workspace 实际保存为 Global
dashboard 创建 key 表单有 SCOPE = Workspace / Peer / Session 三选一，填了 ID 字段后保存，列表里显示 SCOPE = Global。
可能是 Honcho v3 dashboard UI 的 bug，也可能 v3 这版"workspace scope"还没真实施。
教训：3 把 key 创建后回 dashboard 检查 SCOPE 列。如果都是 Global 不要慌，下一坑解决。
坑 4：Global scope key 几乎只有"创建空 peer"权限
实测：
- ✅ POST
/v3/workspaces/teamos-prod/peers(create peer with id) → 201 Created - ❌ POST
/v3/workspaces/.../peers/{id}/messages(add message) → 401 JWT not permissioned - ❌ session.add_peers / session.add_messages / dialectic chat / upload MEMORY.md → 全 401
意味着 Global scope 等于"只读 + 建空 peer"——干不了 hermes 业务真正需要的事。
教训：必须用 admin scope key（dashboard 创建时 ADMIN ACCESS = Yes）。Global scope 在 Honcho v3 cloud 上实际等于纸面权限，不实用。
坑 5：Honcho SDK _ensure_workspace 每次 init 都 POST /v3/workspaces
SDK 行为：每次 Honcho(api_key=...).peer(...) 第一次调用，内部强制 POST /v3/workspaces "get-or-create"。
- admin scope key → POST 成功（自带创建权限）
- Global scope key → 401
- workspace 已存在不影响（SDK 不检查是否存在，硬调）
我们 patch 了 SDK 把这步跳过（_workspace_ensured = True，详见 ../system/Honcho 接入指南）。
但用 admin scope key 后这个 patch 其实不需要——admin 能成功 ensure。我们保留 patch 是因为：
- 跳一步没必要的网络调用，启动更快
- 不冲突，纯优化
教训：admin scope key 选了，patch 就当冗余优化保留。
坑 6：admin scope key 能调 delete_workspace —— 必须 patch 屏蔽
admin scope = 全权 = 包括能调 client.delete_workspace("teamos-prod") 一键删团队记忆。
虽然 hermes 业务代码不会主动调，但：
- LLM 误调（prompt injection / 幻觉）
- 容器入侵者
- 未来开发者手滑
任意一个就团队记忆灭。
修复：monkey patch Honcho.delete_workspace 重命名为 delete_workspace_DISABLED（详见 ../system/Honcho 接入指南）。这样调它会 AttributeError，永远不可能误删。
教训：用 admin scope 必须配 monkey patch 屏蔽 delete_workspace。这两件事是配套的。
最终架构
3 hermes 容器
├── /opt/data/honcho.json (含 admin scope key + workspace=teamos-prod)
├── /usr/local/lib/python3.11/site-packages/honcho/client.py (已 patch)
│ ├── _ensure_workspace: skip (优化)
│ └── delete_workspace: DISABLED (安全)
└── 内置 honcho plugin → 4 工具暴露给 LLM
↓ HTTPS
Honcho cloud (api.honcho.dev)
└── workspace=teamos-prod
├── peer: admin / guohua / linjun (real users)
├── peer: hermes-admin / hermes-guohua / hermes-linjun (AI peers)
└── sessions accumulating dual-peer dialogue长期演进
- 3-6 个月后：评估 Honcho 跟同事画像准不准。如果好用 → 写一份 ../system/团队画像综合 让 admin 定期抽 hermes-admin reasoning 出团队/品牌洞察
- Honcho v4：可能会修 SCOPE/workspace key 这些边角 case，到时候撤掉 monkey patch
- upstream issue：考虑给 plastic-labs 提 issue 反馈"workspace scope 实际是 Global"的 dashboard UI bug
关联
- Honcho — 实体页
- Honcho memory — 范式概念
- Honcho 接入指南 — 实施步骤
- HERMES_HONCHO_RETRIEVAL_GUARDRAILS — 隐私铁律
- mem0 — SUPERSEDED 前任
- Zilliz Cloud Milvus — SUPERSEDED 原后端
- Mem0 vs llm-wiki Division of Responsibility — SUPERSEDED，需要重写为 Honcho vs llm-wiki